Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0049/414.txt

Text File | 1997-04-16 | 21KB | 464 lines

Info-Atari16 Digest   Friday, August 25, 1989   Volume 89 : Issue 414

This weeks Editor: Bill Westfield

Today's Topics:

                     Apple ][ to ST data transfer
                      Re: Multitasking on the ST
                   Re: Re~2: Multitasking on the ST
                      8Mb on an ST, bounced mail
                 DeskJet Plus power-up sequence fix!
                    Re~2: New Atari 68030 Machines
                           Modula-2 (again)
                           Program Speedup
                        WOA @ DALLAS -- great!

----------------------------------------------------------------------

Date: 19 Aug 89 07:30:54 GMT
From: cs.dal.ca!iisat!brains![e-mail]  (George Seto)
Subject: Apple ][ to ST data transfer
To: [e-mail]

Apple ][ to ST data transfer:

   [e-mail].c @cmu.unige.ch

   sorry, but the ST won't be able to directly read the data from the Apple
][ disks. Apple used an odd method of formatting disks, which means you will
have to hook the two together via Serial ports and communications programs.
If you can, you should be able to transfer at speeds up to 19,200 bps. I have
successfully connected between and Amiga (a friends) and a 1040STf with not a
byte lost. You probably will need a null modem and may have to have the two
computers handle it with one as a host system. If on the ST, you have Flash
or Interlink, you can do that fairly easily as the host system. Interlink is
easiest as it has a special "mini-bbs" built-in to it. With Flash, you can
handle it with Do files or with the Remote control Accessory.  Of course, the
whole thing can be done manually.
--
   -===------===-    From George Seto at Cerebral Cortex BBS System
  -==-==----==-==-   [phone] 3/12/2400 8N1 24h/7d
 -==-------==------  [e-mail]
  -==-==----==-==-

------------------------------

Date: 13 Aug 89 11:43:01 GMT
From: mcvax!unido!tub!tubopal![e-mail]  (Thomas Cervera)
Subject: Re: Multitasking on the ST
To: [e-mail]

In article <[e-mail]> [e-mail] (Leo de Wit) writes:
=In article <[e-mail]> [e-mail] (Thomas Cervera)
 writes:
=|  But isn't there any software solution to that ? (I'm looking on primitive
=|MMU versions on PDPs where the operating system does a part of context-
=|saving work on failed EMT or TRAP recovery). The LSI11 processors are very
=|much like the M68k family. Or is this really impossible on 680x0 ? (Remember,
=|I'm only a dumb physicist :-) )
=
=The problem is that for instance a page fault can emerge whilst in the
=middle of an instruction. Whereas the 68010, 68020 etc. store much
=information on the stack at a BUSERR (29 words if I'm correct), the
=68000 only stores 7 words, which is not sufficient to resume each type
=of instruction.  For instance:
=
=    movem.l   (a3),a2-a5
=
=Since this instruction modifies the contents of a3, it cannot be resumed
=when a bus error occurs after a3 has been modified (and the instruction
=has not yet completed).

  I'm not that familiar with the 68000's hardware and pin configuration.
But isn't there a pin telling the non-existent MMU 'shut up, I'm working on
an instruction right now !' ?
  Sure, the MMU must be able to hold it's BUSERR signal back until the CPU
drops this line and tries to fetch the next instruction.
  If this is possible, error recovery on BUSERR should not be a problem.

--
Thomas Cervera         | UUCP:   [e-mail]
SysMan RKOpdp (RSTS/E) |         ...!unido!tub!opal!alderaan (Europe)
D-1000 Berlin 30       |         ...!pyramid!tub!opal!alderaan (World)
Motzstrasze 14         | BITNET: [e-mail] (saves $$$)

------------------------------

Date: 13 Aug 89 11:22:51 GMT
From: mcvax!unido!tub!tubopal![e-mail]  (Thomas Cervera)
Subject: Re: Re~2: Multitasking on the ST
To: [e-mail]

In article <[e-mail]> [e-mail] (Martin Boening) writes:
>What's all this about NEEDING memory segmentation for Multitasking. You can
>have Multitasking without memory segmentation. (Of course memory segmentation
>helps a lot). Just look at several multitasking OSs for the ST, all running
>without a REAL MMU: OS-9/68000, IDRIS, RTOS-UH/Pearl, MINIX-ST, Xinu,
>(what else ?).
> [...]
>I hope this convinces everybody that multitasking is possible (even if not
>feasible due to lack of speed) on the ST.



  Encore une fois:
  Multi tasking is possible but USELESS for every-day operation on a machine
where every little bullsh*t program can trash important memory. You definetely
CANNOT shrink a system's kernel PLUS working variables completely into 2048
bytes. BUT THAT'S ALL PROTECTED MEMORY YOU HAVE ON AN ST. Oh, sure, you could
execute what's in the hardware registers.
  I don't want to think about wasted time during software debugging on a
machine where ANY program can produce unpredictable and perhaps unreproductable
reactions of ANY program running on it (INCLUDING THE OPERATING SYSTEM ITSELF)
if it's not coded correctly. (Maybe your printer daemon crashes the system
every time you print more than 42 asterisks).
  It is not neccessary at all that YOU are the source of this behaviour, some-
one else who has written a program currently running in your system's background
could be the cause ! Perhaps YOU WILL NEVER KNOW !
  If you have an MMU and if your 'crash exception handler' is working correctly,
only the nasty program will die WITHOUT affecting others. Because of that you
can exactly determine what's going wrong there.

  Of course, this is not only relevant for multi tasking systems on the ST but
for all multi-program environments on this machine (including TOS). BUT it's
a matter of fact, that multi tasking means multiplying the probabilty of crazy
system behaviour !

--
Thomas Cervera         | UUCP:   [e-mail]
SysMan RKOpdp (RSTS/E) |         ...!unido!tub!opal!alderaan (Europe)
D-1000 Berlin 30       |         ...!pyramid!tub!opal!alderaan (World)
Motzstrasze 14         | BITNET: [e-mail] (saves $$$)

------------------------------

Date: 20 Aug 89 13:05:17 GMT
From: mcvax!ukc!acorn!moncam![e-mail]  (Dave Emmerson)
Subject: 8Mb on an ST, bounced mail
To: [e-mail]

Sorry for posting this here, my mail seems to be bouncing a lot lately, I'll
try to make it generally interesting to compensate..

Firstly, the guy in Alaska enquiring about the 2/4 Mb expander board :
There are none left, I can't post you the photography without a commitment
to run a batch, but if you mail me a fax number, I'll gladly fax you a copy
so's you can see what's what. Your machine sounds like Harry's so should be
OK. Alternatively, I can snailmail you a set of 'stats.

Two or three people have asked about the possibility of going beyond 4Mb
by adding a second MMU. Without having more info on the internals of the
MMU, I can't really comment, but physically this would be a messy job. A
cleaner solution for 8Mb is simmering at the back of my tiny cranium at
the moment. If anyone cares to experiment/comment, it goes a bit like this:

A22 is disconnected from the MMU, and the MMU's A22 pin is tied low. It now
can't distinguish between the first and second 4mb (nor between the 3rd and
4th, but this is irrelevant to our purpose). A22 is then ORed with each of
the 4 cas_ lines in a 74F32. The 4 resultant outputs are used to replace the
existing cas_ lines to your existing 4Mb. You should try this first, to make
sure your ST still works reliably. I have heard rumours that some models
may have marginal timing. If yours has, this extra 5nS may make it unreliable.
Soak test it like this for a few days. NB: don't forget to add those series
resistors in each cas_ line!
If my guess is correct, you should be able to read garbage from the 2nd 4Mb
space without your ST crashing. If not, let me know, and I'll try to check
it out. (Anything written to that area should just vanish)
Adding the 2nd 4Mb is then fairly simple, all the connections are paralleled
with the first 4mB EXCEPT the 4 cas_ lines. These are obtained by inverting
A22 in a 74F04, and ORing the result with the 4 ORIGINAL cas_ lines in
another 74F32. The resultant outputs are the new cas_ lines for the new
memory.
The new 4Mb is capable of all the DMA functions of the original, but you
have a tiny bit more work to do yet.
Because the TOS only looks for up to FOUR Mb, you'll have to write a small
patch to modify some of the system variables, to get all 8Mb in use, and
this code will have to be run immediately after booting. I don't have a copy
of the developer's manual handy, so I can't say how many, nor which ones.
Quite likely you'll find it easiest to refer to the disassembly listing for
the TOS and pick a suitable point to re-enter it at with one register changed
to hold the new RAMTOP, doing most of the cold reset over again. If you do,
don't forget to make your patch check to see if it's already been run, or
you'll loop forever!
I can't actually check this out myself, Harry is still on hols, and I doubt
if he feels he'll need (or can afford) 8Mb anyway, even running EMACS.
Where you will actually physically put all this extra hardware is of course
another matter. If your 4Mb expansion board uses DIL 1Mbit memories, you'll
probably be able to piggyback the new ones.

Lastly, a note for those debating multitasking:
Since multitasking code has to be relocatable, all addressing has to
be of the PC-relative type. On a 680x0 this limits addressing range to
PC +- 32K. If every task had 32K of non-code space above and below it, the
chances of corruption of other tasks are minimal, even without an MMU....

Dave E.

-Disclaimer-
Since my employer doesn't seek my approval of his opinions, I haven't
sought his.

------------------------------

Date: 20 Aug 89 02:57:53 GMT
From: nic.MR.NET!ns![e-mail]  (John Logajan)
Subject: DeskJet Plus power-up sequence fix!
To: [e-mail]

HP DeskJet Plus / Atari ST power-up sequence problem -- solved!

I have discovered that if the Atari ST parallel (printer) port
STROBE line (normally high) is pulled toward ground (low) by a
heavy load (such as a powered-off HP DeskJet Plus), the ST STROBE
line will thereafter stay low until the load is removed (by
powering up the DJ+), and until software intentionally sets the
STROBE line high again.  (Weird note: the STROBE line has to be
pulled low for something on the order of 1/2 second or longer for
it to "stick" low -- I do not know why this is.)

Once the STROBE line gets stuck low, the DJ+ responds with a BUSY
set high.  The Atari TOS will not send any data to the printer
while the BUSY line is high -- so no printing can take place.

There are six solutions to this grid-lock (I recommend #6):

1.) Power up the DJ+ first and the ST second.  (Then the ST will
    never see a heavy "low" load on the STROBE line.)

2.) Push the Atari RESET button.  (The reset sequence sets the
    STROBE line high, clearing the problem.)

3.) Have a software routine which sets the STROBE line high.  (No
    sense putting this in the auto folder to clear it on reboot,
    since reboot itself clears the problem -- until next time.)

4.) Power cycle the DJ+ with a print job in the ST "queue".  (You
    will lose the first part of the print job, and I think the
    print job must be a minimum length of bytes long to get it
    over the DJ+ power-up self-test delay.)

5.) Momentarily ground the BUSY line with a print job in the ST
    "queue".  (I'm not sure if you will lose the first byte of
    your listing with this method.)

6.) Install a PNP transistor in the STROBE line.  This fix is
    much simpler than it may seem.  Also it simultaneously solves
    the heavy loading problem the DJ+ puts on the Atari STROBE
    line.  (Without the transistor, the loading on the STROBE line
    appears to push it near the 0.8 volt level limit.  The DATA
    lines do not seem to have same problem, their low levels seem
    to be well within limits -- so no buffering seems needed.)

You need:

 - One 2N2907 (or practically any PNP transistor)

 - Access to the Printer cable wires for pin #1 (STROBE) and any
   ground pin (pins 18-25 on the Atari end, or pins 19-30 on the
   DJ+ end.)  I managed to do this inside the cover of the
   Centronics-type connector.

Step #1  Disconnect the STROBE wire from pin #1.

Step #2  Connect the Emitter (E) wire of the transistor to the
         Printer side of the wire/pin#1 split you did in step #1.
         (It depends upon which end of the cable you put your
         transistor into.)

Step #3  Connect the Base (B) of the transistor to the Atari side
         of the wire/pin#1 split you did in step #1.

Step #4  Connect the Collector (C) of the transistor to one of the
         ground pins (18-25 Atari end, or 19-30 DJ+ end.)
         [Caution: Metal cased transistors often have the case
         electrically connected to the Collector -- hence the case
         will most likely be grounded -- avoid having the case
         touch anything that should not be grounded.]

Step #5  Close up and/or wrap up.  Make sure the transistor case
         and connections are not touching anything they shouldn't
         be touching.


Figures:

                          -----> Ground
                          !
                         / C
                     B !/
from Atari STROBE >----!
                       !\
                         \ E
                         !
                         ----------> to Printer STROBE
        -------
       /     B \
      / E       \   Metal Can style transistor -- common pin
    ==           !  configuration -- bottom view.
      \      C  /
       \       /
        -------

        ----
        ! C  \
        ! B   !     Plastic Flat sided style transistor -- common
        ! E  /      pin configuration -- bottom view.
        ----


Appendix:

              Speed on the parallel printer port.

 The Atari does screen dumps at about 1250 bytes/second.

 The Atari does text dumps at about 714 bytes/second.

 A GFA Basic program I wrote dumps graphic bytes to the DJ+ at
 about 2174 bytes/second.  Since an 8 by 8 inch graphic picture
 with 300dpi density requires 720,000 bytes -- you can see that the
 dump alone should take almost 6 minutes for even the GFA program.

 This all suggests that one might want to take advantage of the
 DJ+'s mixed mode graphic commands, where "blank" space is jumped
 over.  Software should be able to "count" over these locations
 much faster than it would take to dump them in dumb mode.

THE END.

--
- John M. Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428  -
- [e-mail] / ...rutgers!umn-cs!ns!logajan / [e-mail] -

------------------------------

Date: 20 Aug 89 11:50:18 GMT
From:
 gem.mps.ohio-state.edu!rpi!crdgw1!ge-dab!peora!cmpfen![e-mail]
u  (Bob Breum)
Subject: Re~2: New Atari 68030 Machines
To: [e-mail]

[e-mail] (Peter Ted Szymonik) writes:

>Accordin to Sam Tramiel in this month's START the '030 (aka TT) will
>come in many onfigurations, one being a 6 meg machine which will have
>TOS 1.4 built-in, will run UNIX 5.3.1 as a $299 add-on option and will
>aslo emulate MS-DOS (and the Mac no doubt with Dave Small's Spectre GCR.)

I want both TOS 1.4 and UNIX, at the same time.  Will the TT run
multiple TOS 1.4 sessions _under_ UNIX, like an 80386/ix machine can
run multiple DOS sessions under UNIX?  Now _that_ would be the best of
all possible worlds: Several UNIX windows, including a couple of TOS
sessions and a couple of MS-DOS sessions mixed in with standard UNIX
tasks.

--
Computer Fenestrations                                                Bob Breum
Post Office Box 151
Lake Monroe, FL 32747 USA
[phone]                                            "C is the new BASIC"

------------------------------

Date: 21 Aug 89 02:00:29 GMT
From:
 agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird![e-mail]
 (News System Account)
Subject: Modula-2 (again)
To: [e-mail]

If I might burden the net with another request;  I would be interested
in M2 sources or pointers to said sources thereof.  We thank you for
your support.

BTW, savin' my pennys for a TT.  Un*x at home!  MS-DOS too! (Well, they DO
have alot of programs.)

-------------------------------------------------------------------------------
 Bill Hodges                    |  Me?  People who speak for the Air Force get
 [e-mail]  |  paid a lot more than I do! I just work here.

------------------------------

Date: 21 Aug 89 03:18:52 GMT
From: [e-mail]  (Chris Long)
Subject: Program Speedup
To: [e-mail]

I am currently working on an assembly-language program that takes
quite a while to run (*weeks* to *months*).  Does anyone have any
good ideas or pointers to books and/or articles which would help me
to speed it up?  Are there speed upgrades for the Atari ST available?
No floating point operations are involved.

Also, what happened to ssyx.ucsc.edu?  I tried an anonymous ftp
there to pick up a copy of the MJ C compiler, but apparently Atari
PD programs are no longer archived there.  Is there somewhere else
that I could pick up a copy of it?
--
Chris Long, 272 Hamilton St. Apt. 1, New Brunswick NJ  08901  [phone]

"It has no normal subgroups" was Tom's simple observation.

------------------------------

Date:         21 AUG 89 00:09:56 CST
From:     Z4648252 <[e-mail]>
To:       <[e-mail]>
X-Orig-To: [e-mail]
Subject:  WOA @ DALLAS -- great!

Hello everyone,

    I just returned from the World of Atari show at Dallas and, from a
user's point of view who bought over $300.00 worth of goodies, it was
fantastic.  If there is an Atari Fest in your area, you owe it to yourself
and your developers to attend.
    Meeting the ST gurus, programmers, and developers is a treat.  Everyone
which I met demonstrated patience, in spite of the constant crowds, and were
more than eager to discuss modifications complete with the hows, whys and
why nots.
    One program utility disk which I purchased and am so impressed with
that I'm barely able to contain myself is DC Utilities by Double Click.
There have already been ample reviews and mentions of this disk so I'm not
going to sum it up.  However, I do wish to praise one program and rate it
as a "must have".  On the disk is a program named DCSQUISH.  Basically, it
'squishes' any executable program, saves a copy of the original, and gives
you an executable squished copy back.  Disk space savings appear to average
about twenty percent with some squished files being much higher in savings.
I have saved 800k of disk space in my C partition, if that is an indicator
of savings.  Time of execution of the squished program?  It is FAST.  On
my Mega2 ST with original Mega roms (1.2), I noticed that Flash, executed
from floppy, came up one second QUICKER.
    Again, nothing but praise for this program and my thanks and
congratulations to Double Click for such a utility.
    Another product which I am now wooing over is Turbo 1.6.  It does
everything that you have heard.  I booted up WordPerfect, loading in a
four paged file.  My Mega, of course, has the blitter.  Doing a down arrow
scroll, it took the Mega without Turbo 1.6 to reach the end of the document
in 23 seconds.  Installing Turbo 1.6 gave me a time of 21 seconds.  Without
the blitter but with Turbo, the time was 27 seconds.  With both turned
off, well.........forget it.  Wasn't even worth timing!
    Turbo 1.6 gives such an improvement and approaches the blitter in
performance that I don't really see the need for the purchase of the
chip.  This is from my impressions as a user and I know nothing about
what is going on behind the scenes of the blitter.  However, Turbo 1.6
"has arrived".  It is a product worthy of purchase and even for the Mega,
makes a substantial improvement.
    World of Atari is a great opportunity for the user.  I hope that if
any other Atari Fest occurs and it is reachable by you, then by all means
go.  Meeting and talking with the programmers gives one a great appreciation
of the products used and indeed, you will feel as if you, as the user,
are part of the process.

Larry Rymal in East Texas <[e-mail]>

------------------------------

End of Info-Atari16 Digest
**************************
-------